We all know the current situation with cloud providers such as Dropbox, Owncloud, Drive, etc. is less than ideal.
The problems are:
– Some of them use proprietary code for the client, so we can’t control the user experience on the desktop.
– They provide different experience based on its application, which may result in diferent workflow and poor integration.
– Integration is very poor. Probably most of this fault is the need for a common API to integrate with the desktop.
– Full support for it is difficult. It needs gvfs support for syncing etc, which is not yet available, and every provider does it own thing anyway.
– Uses of specific API depending on the desktop or file manager. i.e. Dropbox uses nautilus-dropbox package for it’s integration with only Nautilus. This is problematic for users of other desktops or file managers, and also the Nautilus extension API is very limited.
– Need to use tray icons for the menus.
So what should we do?
Design team of GNOME worked on it and mockuped this (the lowest one): https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/other-locations.png
This allows cloud providers to add custom menu actions for them, which allow to avoid the use of tray icons and also shows the status of the cloud provider.
Now the technical problem, how do we integrate in the desktop without relying on extensions and allowing other file managers/toolkit/desktops use it, so cloud providers companies start using this integration for any desktop?
Luckely we have a powerful desktop-toolkit-app-agnostic tool. DBus. So I created a DBus API for it and added support for that API in gtk+. This is Nautilus with gtk+ cloud provider support in the sidebar:
Tada! We can see here a cloud provider in the sidebar, using the cloud provider icon, name, status and a custom menu provided by the cloud provider.
How does it works?
Cloud providers expose the DBus API and just listen to it’s calls, acting as a server. Also, the cloud providers implement the dbus method “CloudProviderUpdated”, which notifies to DBus that the cloud provider updated it’s status/icon/path or whatever it needs.
Currently available funcionalities are:
– GetIcon: which retrieves the cloud provider brand icon.
– GetPath: which retrieves the folder where the cloud provider stores its files.
– GetName: which retrieves the name of the cloud provider
– GetStatus: which retrieves the status (idle, syncing, error) of the cloud provider
And finally, it can expose a full GMenuModel through DBus for its use for any action.
The good thing about this is that we can extend the DBus API to whatever it’s needed, so if someone working in a cloud provider have some suggestion, say it and we will add it.
What can we do for cloud providers companies that are not interested on it? We can add support for it anyway (as far as it’s API/daemon allows), if we have access to the daemon or some APIs we can create a small shim/bridge which isolates the daemon/API calls and exposes the DBus methods, that “easy”!
Now, I guess you would like to see an example of a cloud provider implementation of this desktop integration. Here it is:
This example uses all capabilities, and it updates its status every two seconds.
And what toolkits/DE’s/apps need to use them? Here is an example:
So far it works better than expected. So future work is:
– Make sure it provides what all cloud providers need
– Convince cloud providers companies to use this instead of random extensions, specific DE code, or complex clients. And if not, implement a shim/bridge on our own for them.
– As you can see, it’s in a wip branch, so it’s needs more work.
Hope you like the progress we are doing to integrate some 3rd party services in our linux desktop.
csorianognome.wordpress.com 
This looks cool.
Is there a bug report tracking this?
Why is it in GTK+? This feels like it should be in some other library.
The D-Bus API should be using properties rather than methods. You might want to read http://dbus.freedesktop.org/doc/dbus-api-design.html.
The API should probably be a freedesktop API; this is not at all GNOME specific, and if Dropbox are going to write a client which uses it, it had better work on every desktop otherwise it’s a waste of their time.
No there is no bug report, it’s just an effort I started doing.
>Why is it in GTK+? This feels like it should be in some other library.
Because its UI representation depends on the toolkit. Everything else is the DBus API. Also I’m not sure we want gtk+ to depend in another library. It’s just a DBus API, let’s not make it complex.
>The D-Bus API should be using properties rather than methods. You might want to read >http://dbus.freedesktop.org/doc/dbus-api-design.html.
Probably my design it’s the worse. It’s my first time with dbus, and gnome-shell use it like this.
>The API should probably be a freedesktop API; this is not at all GNOME specific
It’s not that I wouldn’t like to, but as I said, it’s a wip, not going to make it freedesktop API day 1.
>if Dropbox are going to write a client which uses it, it had better work on every desktop otherwise it’s a waste >of their time.
Currently it’s like that, dropbox only installs nautilus-dropbox, which was created by them. So far this is already better =)
Also, as I said in the post…it’s a DBus API, anyone can consume it. It’s desktop agnostic by design. You don’t need anything special to make it work on other desktops… Not sure I understood your comment at all.
> Probably my design it’s the worse. It’s my first time with dbus, and gnome-shell use it like this.
Well, hopefully you find that article useful. 🙂 Let me know if anything’s unclear in it and I will update it.
> It’s not that I wouldn’t like to, but as I said, it’s a wip, not going to make it freedesktop API day 1.
Sure, but I think you should definitely plan to move it to fdo soon, before anyone implements it. And part of that process is getting other desktops involved in the design and review of the API
> Also, as I said in the post…it’s a DBus API, anyone can consume it. It’s desktop agnostic by design. You
> don’t need anything special to make it work on other desktops… Not sure I understood your comment at all.
I could have been clearer, sorry. My point is that Dropbox don’t want to write one client for GNOME, one for KDE, one for XFCE, etc. But KDE won’t want to implement a D-Bus API which is namespaced in ‘org.gtk.’ and whose specification is one implementation in the GTK+ git repository which could change (deliberately or inadvertently) at any time. To be implementable by any desktop, this needs to be a specification on freedesktop.org.
I realise my comment sounded a bit negative, and I didn’t mean that. I’m giving critical comments because I want this API to be a success, because it’s a good idea!
Be a freedesktop specification is a must, we already planned like that, just not in the actual state.
Cloud providers only need to expose the API, no specific toolkit involved (except the current temporary org.gtk dbus path) which as you said need to change before being implemented by them. But we can start playing with it as a proof of concept.
I did the blog post to anounce that I’m doing this effort proposal and opening the discussion with others DE,cloud providers, etc.
And yes, thanks for the article you linked, it cleared me most of the things (and now I need to change almost all the DBus part).
Also, how about some API which directs the cloud providers towards being a little more open about privacy? For example, a PrivacyPolicy property which has to be filled in with the URI of the provider’s privacy policy, to make it easily accessible to the user?
You agree with their privacy terms when you do an account for the provider. So you should visit its webpage and read them. But adding another menu item for something that you read just the first time, it’s too much.
It doesn’t necessarily have to be presented as a menu entry — for example, it could be a notification the first time you mount the cloud share saying ‘did you know, Google Drive’s privacy policy is here, defining where your data is stored’. That would make the privacy implications of using cloud storage more pertinent in the user’s mind, which has been demonstrated to encourage more privacy-focused behaviour (I can dig up citations if you are interested; there’s a lot of literature by Sören Preibusch on it).
More concretely, it would be good if this API considered the User Data Manifesto (https://userdatamanifesto.org/) and enforced it or steered cloud storage providers towards it.
You should probably also think about how this should interact with the work done as a result of the privacy campaign; the privacy panel, for example.
I would also allow to have more then one folder to be set. If there are more then one, then clicking on the e.g. Dropbox Item leads to an overview of all this folders.
Why? I e.g. have btsync with multiple folders shared, some for private use, some for the company.
Then Dropbox should create a folder which contains all the other ones. The single click action opens a path, if the provider has support for multiple folder, just put them in that path and you achieve the same result.
I think the argument was that you should not hardcode the API to the way a specific provider works, but make it somewhat generic to accommodate different use cases. Let’s say there’s a synchronization client FooBox, and it doesn’t operate on a single central directory like Dropbox does (~/Dropbox), but it allows you to sync several separate directories. Let’s say I configure FooBox to sync my ~/Documents, ~/Pictures and ~/Invoices. What happens after I click on the FooBox menu item in Nautilus?
Aaaah got it!
And indeed I need to look all cloud providers for a abstract enough API.
Awesome work happening! We (elementary) would love to work with GNOME and GTK+ on this and implement it into our file manager as well. Where is the best place to collaborate?
whops my comment didnt go through. Reach me on IRC in #gnome-hackers as csoriano
Reblogged this on Stephen Victor and commented:
Excellent work by the GNOME Nautilus team.
If all these comments mean we could get Google Drive natively working on elementary I’d happily pay. Please tell us so!
Hey, not really, this is about the integration of the sync client those products have.
How is this project/library going?
I have looked for a specification at freedesktop , but did not find one, is it in the making?